IBIS Macromodel Task Group Meeting date: 25 June 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: Ambrish Varma Ken Willis Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad asked if we would have any trouble getting people to attend next week's meeting because of the US holiday on Thursday the 4th. Only one attendee said they couldn't make it next week, so the meeting on July 2nd will occur as scheduled. - Bob noted that the ibischk 7.0 parser will be available shortly and asked interested parties to be ready to try it out. He noted that final details of the licensing agreement are being completed. ------------- Review of ARs: - Fangyi to modify BIRD197.3_draft_5 to create draft_6 per last week's discussion. - Done. (Note: the BIRD NUMBER field in the new version sent to ATM remained 197.3_draft_5 instead of being bumped to draft_6). -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the June 18 meeting. Bob moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: BIRD197.3_draft_5(DC_Offset): The group reviewed the latest version Fangyi had sent to ATM incorporating last week's changes. Arpad noted one typo, signle -> signal, in the "Definition of the Issue" section. Arpad also asked a question about the following sentence: “It is assumed that the waveform input to the Rx AMI_GetWave function is the physical Rx input waveform minus this DC_Offset.” He noted that the EDA tool computes the value of the DC_Offset from the channel's step-response and passes it in to AMI_Init(). He wanted to make sure this sentence should not be interpreted as "the input waveform to the Rx GetWave function is centered about the X-axis", because the EDA tool does not know what the Tx GetWave() function might return. Walter confirmed that it should not be taken to mean that the Rx input waveform must be centered about the X-axis. He said the Tx GetWave() output is likely to be centered about the X-axis, so the waveform passed into the Rx is likely to be centered about the X-axis, but it's not required to be. Radek agreed with Walter's interpretation. Randy asked whether we had yet answered the question he'd previously raised about what the EDA tool should do with the output of Rx GetWave(). Should the EDA tool shift the output waveform for display? He wanted to make sure we'd provided clear guidance to the EDA tools. Walter said the EDA tool can generate an eye diagram with the exact waveform that is returned by Rx GetWave(). It can use the NRZ_Threshold to compute BER, etc. How the tool displays the waveform is up to the tool. Arpad pointed out the phrase "physical waveform" in this sentence from the "Other Notes" section of the DC_Offset description: "The Rx AMI_GetWave output waveform is the physical waveform at the Rx latch. It can have a non-zero DC component, which can be time-varying." Walter said he still didn't know what "physical waveform" meant. We don't really know what the reference point is, and the waveform returned by Rx GetWave may or may not have a DC component. He said that the Rx model returns whatever waveform it wants, and it returns the corresponding threshold in the NRZ_threshold parameter. He noted that if the waveform coming out Rx GetWave() is zero-centered, as is true for all current models he knew of, the tool could display the raw waveform or add DC_Offset at its discretion. Arpad summarized Walter's position by saying the only thing incumbent on the model is to return a threshold value that corresponds to the output waveform. Randy noted that we are not really defining what to do. He said it's convenient if the tool adds the DC_Offset back in for display of the waveform, but if the model has returned a waveform that already contains the offset this could be a problem. By not defining things, we may end up with inconsistencies in the way various tools display the same output waveform. Arpad asked if this was ready for submission to the Open Forum. Bob moved that we submit Fangyi's latest draft, with the one typo fix noted by Arpad, as BIRD197.3. Randy seconded. There were no objections. Arpad asked if he should just make the typo fix and submit it, since Fangyi was not in attendance. The group agreed, and Arpad took the AR to submit BIRD197.3. Complex C_comp modeling: Arpad asked about the new sentence proposed for the [Component] Usage Rules: "The 'Die' location refers to the Buffer_I terminal of a [C Comp Model], if [C Comp Model] is present and includes the Buffer_I terminal." He asked if this change was up to date with IBIS 7.0. He noted that BIRD189 had introduced 3 terminal types, but this section of this BIRD did not address all 3. Randy noted that the text shown preceding this new sentence was from IBIS 7.0, and that this sentence is up to date with respect to IBIS 7.0. Bob agreed and noted that for IBIS 7.0 the decision had been taken to leave the 'Die' and 'buffer' locations merged together from the point of view of the Si_location and Timing_location SubParams. Radek asked why it was necessary to include Si_location and Timing_location changes in this BIRD at all. Randy said that if you're using a [C Comp Model] you can point to the new Buffer_I terminal as the location for your SI or timing location. Arpad agreed and noted that the new Buffer_I terminal is not the same location as the buffer terminal in the interconnect section. It is separated from the buffer terminal by other series elements (Note: see "Input Filter Circuit" in Figure X in the BIRD draft). Arpad said the language in [C Comp Model] Usage Rules: could be confusing. He noted that it says [C Comp Model] overrides [C Comp Corner] or C_comp*, but the next sentence says [C Comp Corner] is required if [C Comp Model] is present. He suggested we change the text to state that [C Comp Model] overrides the others during the simulation, but [C Comp Corner] is required because it's necessary for deriving the K-T curves. Bob asked if [C Comp Model] were only provided for the typ case, but [C Comp Corner] were provided for typ/min/max, would [C Comp Model] override [C Comp Corner] for min and max? Randy said normal precedence rules say it would. If [C Comp Model] exists at all, it overrides the others in all cases. He also referred to the File_IBIS-ISS rules section as an example. It states that if a min or max entry is NA then the typ value shall be used. Randy noted that you might only provide one typ case for the File_IBIS-ISS but pass in a parameter controlling the corner settings. Arpad questioned the following sentence in Param rules: "The Param values shall all be numerical or all string values (or NA)." He said this was confusing and implied that if multiple parameters were used they all had to be the same type. He proposed the following language: "The three corner values of any parameter shall be of the same type." Arpad asked about the section on converting IBIS parameters to IBIS-ISS parameters, particularly: "For example, the Param value “typ.s1p” would be converted to str(‘typ.s1p’) in IBIS-ISS subcircuits." Randy said this text had been taken directly from existing IBIS 7.0 text. Randy shared his latest modified version in which he had tried to incorporate new language on making sure proper [C Comp Corner] values were provided. Bob expressed concern that "K-T curves" hadn't really been defined. Randy noted that the point of the section is that [C Comp Corner] will be used by the EDA tool to develop the K-T curves. Bob and Arpad proposed language changes intended to remove any reference to a specific algorithm or prescription for using the [C Comp Corner]. Curtis expressed concern that we could water down Randy's language so much that we gave the model maker no indication of how they could decide that their [C Comp Corner] values were good. Walter suggested we state that "[C Comp Corner] values may be used by the EDA tool for C_comp compensation." Walter noted that there were other ways to do C_comp compensation, but they were all much harder than using [C Comp Corner] so tools would use [C Comp Corner]. Radek objected to the term "may" (may be used by the EDA tool). He noted that an EDA tool should be able to connect the buffer model to the test load specified in the model's v(t) waveform (e.g., [Rising Waveform] or [Falling Waveform]) and generate that exact waveform. So, we have to be precise about specifying the C_comp compensation rules. Arpad noted that further discussion will be needed. - Randy: Motion to adjourn. - Bob: Second. - Arpad: Thank you all for joining. AR: Arpad to submit BIRD197.3 to the Open Forum per Bob's motion. ------------- Next meeting: 02 July 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives